【Mercari Tech Conf 2018 レポート】メルカリ Web の新アーキテクチャについてのセッション『Web Application as a Microservice』#mtc18

【Mercari Tech Conf 2018 レポート】メルカリ Web の新アーキテクチャについてのセッション『Web Application as a Microservice』#mtc18

2018/10/04 に行われた『Mercari Tech Conf 2018』で発表されたメルカリ Web の新アーキテクチャについてのセッション『Web Application as a Microservice』のレポートです。
Clock Icon2018.10.05

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Web Application as a Microservice

メルカリWebはメルカリの成長を支える一角として開発され、約2年間メルカリと共に成長してきました。このメルカリWebをWebにまつわる技術の進化や拡大するフロントエンドチームといった変化に強くするためにJP Web Rearchitectチームが誕生しました。このトークではJP Web Rearchitectで実現する新たなアーキテクチャとその詳細、そしてそれを実現した先にある未来についてお話します。

スライド

Web 版メルカリ

  • 組織の変化
  • 技術的な変化

どちらの変化にも対応していきたい

JP Web Re-architect

  • メルカリ Web を改善する

変更に強い柔軟なアーキテクチャ

  • トレンドへの追従
  • Scrap and Build
  • 最初に選択した技術
    • TypeScript
    • React
    • Next.js
    • GraphQL

開発チームのスケーラビリティの向上

  • エンジニアの増加に耐えうるアーキテクチャ
  • 各チームの技術選定を自由に

モノリス

マイクロサービス

モノリス to マイクロサービス?

  • モノリスを全部一気に移行するのは現実的ではない
  • モノリス with マイクロサービス
    • モノリスとマイクロサービスが共存する
    • いずれは全てをマイクロサービスに移行する

Why?

  • リニューアルではなく Re-architect
  • 小さいスコープで移行を行う
  • まずは小さいチャレンジと失敗を積み重ねる

必要最少コープの移動

  • ページ単位で 1 ページずつ移行していく

移行順の決め方

  • 難易度
  • 他改修とのバッティング
  • 十分なトラフィックがあるか
    • 十分なトラフィックがないと効果がわかりづらい

モノリス + マイクロサービス

Web Gateway

  • 各サービスへのバランシングを行う
  • 初期は新旧アーキテクチャ共存のため
  • 将来は Web マイクロサービスのため

パスによる制御

公開範囲の制御

  • 実現が難しそうでまだ WIP
  • 一部だけマイクロサービスにトラフィックを流せるようにしたい

セッション

  • クライアントごとにトラフィックを流す先をセッションで制御する
    • 違う所にトラフィックを流さないように
  • これもまだ WIP

フロントエンドとバックエンドの分離

  • バックエンドのマイクロサービス化はフロントエンドにどのような効果があるのか
    • 日々増えるマイクロサービスの仕様の把握
    • パフォーマンスを意識したコーディング

Backends For Frontends(BFF)

  • 複数のマイクロサービスを束ねる層
  • フロントエンドとバックエンドの責務を BFF で分離する

  • BFF として何を実装するか
    • SPA と相性のよい GraphQL を採用
    • Apollo を使用

セッション同期問題

  • いくつかのマイクロサービスは同一ドメインに展開
  • モノリスとログイン状態の一貫性を保つ必要がある

セッションを管理するマイクロサービス

  • セッション管理を行うマイクロサービスを立てる
  • セッション整合性, データ保存などを隠蔽
  • 他のマイクロサービスからも使うことを想定

どのように同期するか

  • 毎回セッションがモノリスに存在するか問い合わせに行くか?

  • プログラマが知るべき様々なレイテンシ
  • マイクロサービスのセッションサービスとモノリスとの距離は?
    • 約800Km
  • 東京と北海道間の通信
    • GKE は東京リージョンを使用
    • 既存のモノリスは北海道のさくら DC
    • レイテンシを意識して設計を行う必要がある

レイテンシのどのように対応するか

  • ストレージを前段に
  • 日本を縦断する回数を抑える
  • DB は Spanner か Datastore を検討している
  • Node.js + gRPC を使用
    • メルカリでは Go + gPRC がよく使われているがチームとの相性を意識した

フロー

  • 手元のキャッシュ, DB を見てセッションの有無を確かめる

  • 手元にない場合, モノリスにセッション有無を問い合わせる

  • 得たセッションから, モノリス API へ認証情報を問い合わせる

  • セッション情報を DB に保存

シンプルに保つ

  • 手元にあれば使う, なければ取りに行く
  • 北海道から東京のアクセスはしない
  • セキュリティ/整合性は担保する

まとめ

今は種まきの状態

  • まずは最高のアーキテクチャを実現する
  • 爆発的なスピードで開発できる世界へ
  • 最高の開発体験を実現する

多くのチャレンジ

  • 技術スタック
  • アーキテクチャ刷新
  • 開発体制の進化, スケール

全ては最高の Web のために

おわりに

現在めちゃくちゃマイクロサービス化を推進しているメルカリさんですが, どちらかといえばバックエンドにフォーカスしたマイクロサービスのお話が多い中, 今回はフロントエンド寄りのお話をしていただきました。Web 部分もマイクロサービスにしたいという需要はあると思うので貴重な知見をお話いただいて大変勉強になりました。

その他の『Mercari Tech Conf 2018 レポート』記事

【Mercari Tech Conf 2018 レポート】メルカリの出品機能のモノリスからマイクロサービスへの移行についてのセッション『Listing Service: モノリスからマイクロサービスへ』#mtc18

【Mercari Tech Conf 2018 レポート】メルカリのマイクロサービスプラットフォームチームの取り組みについてのセッション『Microservices Platform at Mercari』#mtc18

【Mercari Tech Conf 2018 レポート】メルペイの進める決済処理のマイクロサービス化についてのセッション『どうして僕らは決済処理をマイクロサービス化しようとしているのか』#mtc18

この記事をシェアする

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.